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(54) Title: ELECTRONIC PAYMENT METHOD FOR PURCHASE-RELATED TRANSACTIONS OVER A COMP 

^ ^ ^ D'EFFECTUER DES TRANSACTIONS LIEES A L'ACHAT 

(57) Abstract 

A method using an open communication 
network (10) to which retailer server stations 
(20) and customer stations (30) are connected. 
According to the method, a retailer server station 
generates a payment slip for the planned purchase 
transaction between the retailer and a customer, 
which slip comprises data on the retailer, the 
customer, the purchased item or service and 
the price; the payment slip is transmitted over 
the network to a payment server station (40); 
the payment server automatically checks whether 
the payment of said price is authorised for the 
customer in question, by querying the client's 
personal account set up in the payment server 
for paying small amounts, or, in the case of 
larger amounts, by making a query over a banking 
network (50) separate from the computer network 
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(10); if the payment is authorised, the payment server generates a cash voucher comprising at least 
and the cash voucher is transmitted to the retailer to enable the purchase to go ahead. 



some of the data on the payment slip; 



(57) Abrtg« 

Le proced* utilise un rfseau de communication ouvcrt (10) sui lequel soot connects des posies serveurs de maichands (20) et des 
oostes clients (30) et comprend: ('elaboration parunposte serveur de marcband d'un ticket de paiement concemant un achat engage entre 
^Set un client, et comportant des mformations relatives a„ marched, au client, a I'objet de 'achat e. & son pnx; la t^snuss.on 
du ticket de paiement via le rfoeau a un poste serveur de paiement (40); la verification automattque par le serveur de paiement s. »e paiemen 
du prix est autorise pour le client concern*, soit par interrogation d'un compte client propre au chent, tenu par le serveur de P™n«nt^ « 
destine aTpaiement des pedis montants. soit par interrogation sur un rfceau bancaire (50) independant du rfeeatj Mnformauque (10). pour 
les paiememTde montants plus elevfc; si la verification est positive. Elaboration par le serveur de payment d un bon de caisse comportant 
au ££ Z parte des informations du ticket de paiement; e. la transmission du bon de caisse au se^ur de marchand afin d autonser la 
realisation dc V achat 



UNIQUEMENT A TIT RE D' INFORM ATI ON 

Codes utilises pour identifier les Eats parties au PCT, sur les pages de couverrure des brochures publiant 
des demandes intemationales en vertu du PCT. 

Royamne-Uoi 
Georgie 
Guinee 
Grecc 
Hongrie 
Irtandc 
ItaBe 
Jxpoa 
Kenya 
Kirghizistan 

RdpuNique populaire deroocraijqiie 
deCorie 

Re"publiqne de Corfe 
Kazakhstan 
Liechtenstein 
Sri Lanka 
Liberia 
Lituank 
Luxembourg 

Monaco 

Republkjue dc Moldova 
Madagascar 
Mali 

Mongol >e 
Mmriunie 



AT 


Annenie 


GB 


AT 


Autricbe 


GE 


AU 


Autralie 


GN 


BB 


Barbade 


GR 


DE 


Belgfcjue 


HU 


BF 


Burkina Fa*o 


IE 


BC 


Bulgirie 


it 


BJ 


Benin 


jp 


BR 


BrfaO 


KE 


BY 


Belarus 


KG 


CA 


Canada 


KP 


CF 


Repubbqoe centrafricaine 




CG 


Congo 


KR 


CH 


Suii*e 


KZ 


ci 


Cote d' I voire 


U 


CM 


Cameroun 


LK 


CN 


Chine 


LR 


CS 


Tchecakyvaqxiie 


LT 


CZ 


Repobbque ichfcqw 


LU 


DE 


Anemagne 


LV 


DK 


Danemark 


MC 


EE 


Ejtonic 


MD 


RS 


Esptgne 


MG 


Fl 


FmUnde 


ML 


FR 


Prance 


MN 


CA 


Gibon 


MR 



MW 


Malawi 


MX 


Mexique 


NE 


Niger 


NL 


Pay*- Baa 


NO 


Norvege 


NZ 


NouveHe-Z^famde 


PL 


Polognc 


FT 


PortngB) 


RO 


Roumanie 


RU 


Federation de Rusaie 


SD 


Soudan 


SE 


Suede 


SG 


Singapour 


SI 


SWnie 


SK 


Sk>vaquie 


SN 


Senegal 


SZ 


Swaziland 


TO 


Tchad 


TG 


Togo 


TJ 


Tadjikistan 


TT 


Tmit*-e4-Tob*go 


UA 


Ukraine 


UG 


Ouganda 


US 


Euatt-Unb d'Amdnque 


UZ 


Ourbtoian 


VN 


Viet Nam 



WO 96/32701 



PCT/FR96/00500 



1 



Proc6d£ de paiement Electronique permettant d'efTectuer des transactions Ii6es 
a 1' achat de biens sur un reseau informatique 

La prfscntc invention concerne un procede de paiement electronique 
5 permettant d'effectuer des transactions li6es a Tachat de biens offeits par des 
marchands au moyen de services telematiques via un r6scau de telecommunication 
informatique ouvert sur lequel sont connect es des postes serveuis dc marchands et 
des postes clients. 

Par reseau informatique ouvert, on entend ici un reseau sur lequel des 
10 particuliers ou des entreprises peuvent librement se connecter a la condition de 
disposer d'une adressc, par cxemple le reseau "Internet". Les biens concemds sont 
des produits ou des services, dont la foumiture est realisee hors du reseau apres la 
conclusion de la transaction, ou des biens immateriels, tels que des informations, 
dont la foumiture peut etre realisee via le reseau informatique. 
15 Divers precedes de paiement electronique ont ete proposes, certains 

6tant deja opcrationnels. 

Plusieurs proccdes sont fondes sur une nouvelle representation de la 
monnaie. II s'agit d'une representation electronique, quelquefois denommee "jeton" 
qui peut etre purement logicielle ou particllement matcriellc, par exemple avec une 
20 carte a puce. Ces proccdes impliqucnt la circulation de monnaie sur Ic reseau 
informatique, ce qui pose des probleroes difficiles de security vis-a-vis de la 
creation dc fausse monnaie. 

D ? autres precedes connus de paiement electronique impliqucnt une 
relation directe avec une banque ou un reseau bancaire. Typiquement, de tels 
25 precedes sont cmploy6s dans les rfseaux dc carte de crfdit conune, par cxemple, 
des precedes bien connus utilisant des terminaux points dc vente relies a un circuit 
carte bancaire ainsi que des procides utilisant des cheques 61ectroniqucs avec une 
signature electronique pour l'authentification de 1'acheteur. Cest une forme dc 
lettre ^engagement 6mise par un acheteur, remise au vendeur et accepts et 
30 rcconnue par une banque. 

Les proc£d£s qui impliqucnt a un moment ou un autre de la transaction 
une relation avec le systeme bancaire traditionnel et la raise en oeuvre d'une 
transaction dans ce systeme prdsentent des inconv^nients. Ainsi, les transactions 
dans le systfcme bancaire ont un cout r£el qui devient prohibitif lorsque le montant 
35 de Tachat est tits faible, par exemple un montant associe a la consultation d'une 
base de donnces. Or, les reseaux informatjques sont bien adaptes a la vente de 
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bicns de faiblc valeur, principalcmcnt des bicns d'infonnation, puisque la livraison 
du bien peut se faire par lc r£seau lui-meme. En outre, l'acces a un rcscau bancaire 
ou un rcscau de carte bancaire doit ctre hautement protege, ce qui exclut 
pratiquement la possibilite d'un acces a travels un reseau informatique ouvert, tel 

5 que le rcscau "Internet" sur lequcl des acheteurs potentiels peuvent se connecter. 

L'invcntion a pour but de fournir un precede permettant d'fviter les 
inconv£nients des procides connus, en particulier un proc&te permettant, sans 
circulation de monnaic 61ectronique, de r£aliser de fa$on simple ct fiable des 
transactions liees a l'achat de biens sur un reseau informatique, et ce aussi bien 

10 pour des biens de prix eleve necessitant une autorisation par le systeme bancaire 
rraditionnel, que pour des biens de faible ou tres faible prix. 

Ce but est atteint grace a un procede du type defini en tete de la 
presente description et comportant, conformement a l'invention, les 6tapes de : 

- elaboration par un poste serveur de marchand connect6 au r6seau 
15 d'une demande dautorisation de transaction, ou "ticket de paiement", concemant 

un achat envisage entrc le marchand et un client, et comportant des informations 
relatives au marchand, au client, a 1'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau informatique a un 
poste serveur de paiement distinct des postes clients et serveurs de marchands, 

20 - verification automatique par le serveur de paiement si le paiement du 

prix est autorise pour le client concerne, la verification ctant effectuee, selon le 
montant du prix a payer, soit par interrogation d'un compte proprc au client, tenu 
par le serveur de paiement, ct destine au paiement des petits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 

25 paicments de montants plus 61ev£s, 

- si la verification est positive, elaboration par lc serveur de paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins une partie 
des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
30 informatique, afin d'autoriscr la realisation de l'achat. 

Ainsi, lc procede selon l'invention est remarquable en ce qu'il 
n ! impliquc ni la creation de monnaie electronique, ni la circulation de monnaie 
eiectroniquc sur lc r6seau informatique. 

La gestion des transactions est effectude par un serveur de paiement 
35 qui seul peut acc£der a un reseau bancaire ou un reseau de carte bancaire, ct qui 
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gere dcs comptes clients non bancaircs sur lesquels des transactions de faibles 
montants pcuvent ctrc cffcctuecs. 

Lc scrvcur de paiement gere egalement des comptes marchands non 
bancaires utilises pour les transactions de faibJes montants. Ainsi, lorsqu'un bon de 
caisse est transmis apres verification par interrogation d'un compte client tenu par 
lc serveur de paiement, le montant de l'achat est debit* du compte client et credite 
sur un compte marchand propre au marchand concemc et tenu par le serveur de 
paiement, ce qui n'entraine pas des couts de traitcment eleves. 

Chaque client dispose d'une identite qui lui est propre pour pouvoir 
utiliser le precede de paiement. II doit £galemcnt disposer d'un compte bancairc 
reel, de preference un compte utilisable au moyen du systeme traditionnel des 
canes bancaircs. La verification par le serveur de paiement peut comprendre une 
phase prcalable de validation de l'identite du client a partir du contenu du ticket de 
paiement. La validation de l'identite est une operation prealable a 1'acces eventucl 
au compte du client, si le montant de l'achat est faible, et/ou a 1'acces au rcseau 
bancairc si lc montant est plus 6leve. Le serveur de paiement comporte de 
preference des moyens, par excmple une base de donnees, permcttant de 
memoriser les relations entrc les identites des clients utilises pour les transactions 
sur le reseau informatique et des identites bancaires (numdros de comptes 
bancaircs ou numeros de cartes de credit) utilisces pour les transactions sur le 
reseau bancairc. On peut eviter de la sorte la circulation d'identitcs bancaiics sur le 
reseau informatiquc. 

Un mode de realisation de I'invention sera maintenant decrit a titrc 
indicatif, mais non limitatif, en reference aux dessins annexes sur Icsqucls : 

- la figure 1 est une vuc gencrale tres sch€matique d un systeme de 
paiement dlectroniquc conforme a i'invention ; 

- la figure 2 est une representation sous forme d'un schema bloc d'un 
serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustre lc d6roulement des operations relatives a un achat 
30 au moyen du systeme de la figure 1 ; et 

-les figures 4A a 4C sont des organi grammes montrant tres 
scheraatiquemcnt les operations effectuces par le scrvcur de paiement. 

Sur la figure 1 est represents de facon tres schematiquc un rcseau de 
telecommunication informatiquc 10 sur Icquel sont connectes des postcs serveurs 
35 de marchands 20, dcs postes clients 30 et au moins un postc scrvcur de paiement 
40. 



20 



25 
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Lc reseau informatique 10 est un reseau ouvcrt ou public, par exemple 
lc reseau denomme "Internet". 

Les serveurs de raarchands 20 sont des unites telles que celles 
courarament utilisees pour des serveurs telematiques connectes sur "Internet", par 
5 exemple des unites organises autour de machines "Unix" multiprocesseurs. 

Les postes clients 30 sont essentielleraent des micro-ordinateuis qui 
sont munis dc moyens de connexion au reseau "Internet" 10, pax exemple sous 
forme d'interfacc "Web". Us serveurs de marchands 20 et de postes clients 30 
utilisent par cxemple des logiciels connus sous la denomination "World Wide 
10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, montre avec plus de details sur la figure 2, 
comprend des unites frontale ct dorsale respect ivement 41 et 42 connectees toutes 
les deux au rescau "Internet" 10. L'unite frontale 41 a une architecture scmblablc a 
cellc d'un serveur classique connecle sur un reseau tel qu^Intcrnet"". L'unit6 
15 dorsale 42 comporte une unite de traitement 43 a un ou plusieurs processeurs, une 
base de donnees 44 comport ant des informations relatives aux marchands et clients 
abonnes au systeme de paiement, ud registre de transactions 45, une unite 46 
d'interfacc avec un reseau bancairc ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire pcrmettant de relier cntre cux les 
20 differents constituants de l'unite dorsale 42. Une liaison securiscc 48 pcrmct une 
communication bidirectionnelle entre l'unitd frontale 41 et l'unit6 de traitement 43. 
La communication avec le rescau informatique 10 est controlee par l'unite frontale 
41 tandis que la gestion dc la base de donnees 44 ainsi que lc controlc de la 
communication avec le rescau bancaire 50 sont assures par l'unit6 dorsale 42. 
25 La base de donnees 44 contient des informations relatives aux clients 

ct aux marchands abonnes au systeme dc paiement. Pour cbaquc client, la base de 
donnees 44 contient l'identit6 systeme du client ("CId"), idcntit6 recuc lore dc 
l'abonneraent au systeme, un comptc de client ou porte monnaie 61cctronique 
("PME") destine au paiement de faibles montants, une identity bancaire telle que 
30 numero de compte bancaire reel ou numero de carte de credit ainsi 
qu'eventuelleroent une clef d'acccs ou mot de passe propre au client. Pour chaque 
marchand, la base de donnecs 44 contient l'identite systeme du marcband ("Mid"), 
identite recuc lore dc l'abonnement au systeme, un compte dc marchand, ou tiroir- 
caissc clcctronique ("TCE") destin* a rcncaisscmcnt des faibles montants et une 
35 identite bancaire telle que numero de compte bancaire reel. 



WO 96/32701 



PCT/FR96/00500 



5 



10 



La figure 3 illustre schematiquement les differentes etapes d'une 
transaction portant sur un achat d'un bien par un client abonne a un marchand 
abonne. II peut s'agir d'un bien materiel dont la livraison au client sera effectuee 
reellement apres conclusion de la transaction ou d'un bien immateriel (tel que de 
l'inforraation) qui peut etre foumie au client par le reseau inforraatique des le 
paiement dlectronique effectue. 

(1) Consultation par le rlipnf 

Par connexion sur le reseau "Internet" 10, un client peut consulter en 
ligne le catalogue ou la "vitrine" d'un marchand quelconque par acces au serveur 
20 du marchand et par visualisation sur I'ecran du poste client 30 des biens ou 
services du marchand. Sur presentation de l'identite CId du client, le serveur du 
marchand peut presenter au client des conditions financiered parliculieres (par 
exemple une remise) applicable a la transaction eventuelle. 
<2\ Demande d'achat 

15 Le choi * du client etant arrete sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
l'identite CId du client. Lorsque cela est necessaire, par exemple pour la livraison 
ulterieure du bien choisi, des informations compl6mentaircs (par exemple une 
adresse et un horaire de livraison prefere). Cela peut etre realise de facon 

20 commode en utilisant un formulaire electronique envoye sur le reseau et destine a 
etre rempli par le client. 

Dans le cas ou l'achat envisage represente un montant 6lev6 ou est 
soumis a des conditions legales, une authentification prcalablc du client peut etre 
souhaitee. Comme on le verra en detail plus loin l'authentification d'un client est 
25 effectuee par le seTveur de paiement 40. Aussi, une demande d'authentification 
provenant d'un marchand est 6mise avantageusement sous la forme d'un ticket de 
paiement de valeur nulle qui est transmis au serveur de paiement par le reseau 
informatiquc via le poste client ct, en cas d'authentification positive, provoque le 
rctour d'un bon de caissc du serveur de paiement au serveur marchand, toujours via 
30 le poste client. Les procedures d'etablisseraent d'un ticket de paiement et de renvoi 
d'un bon de caisse sont decrites plus en detail ci-apres. 

La demande d'achat emise par le client peut porter sur un seul bien ou 
sur plusicurs biens a fournir de facon groupee : "achat panier". 
(3) Elaboration dc la demande de paiem. cn t 
35 En reponsc a une demande d'achat, le serveur marchand 61abore une 

demande de paiement qui peut com prendre les informations suivantes : 
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- Identite du marchand, ("Mid"); 

- Description du bien commande, ou de chacun des biens du panier, en 

cas d'achats groupes; 

- Type de transaction (simple ou panier); 
5 - Identite du client, ("Cld"), 

- Identit6 du bien ou de l'ensemble des biens du panier, ("Old"); 
-Prix de l'objet,("Oid"); 

- TV A (si applicable); 

- Date et heure de remission du ticket de paiement (horodatage par le 

10 serveur marchand); 

- Durec de validite du ticket de paiement; 

- Numcro de serie dans le registrc des ventes du marchand (notamment 
dans le cas ou la transaction a comporte une etape prealable d'authentification). 

L'ensemble des informations ci-dessus est encodee dans une chaine 
15 d'octets qui constitue la cbaine opaque d'un ticket de paiement (ou URL de 
commande de bien, URL dtant les initiates de "Uniform Resource Locator" ou 
Localisateur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP), comrae suit: 

URL http : < SP> < descriptif de la commando , 
20 oil SP est l'adresse "Internet" du serveur de paiement. Le ticket de paiement est 
adresse au poste client. 11 est complete par deux "ancres" logiques qui permettent 
au client soit de 1'annuler, soit de le confirmcr. 

rd) f n vni de I'ordrr- de paiement 

L'ordre de paiement est transmis au serveur de paiement simplemcnt 
25 par validation par le client de l'URL de demande de paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transitcr par le poste client. 
(5) f- ypission du bon de caisse 

Sur reception d'un oidre de paiement, le serveur de paiement 40 le 
ddcode et precede a rauthentification du client et recherche si le paiement peut etTe 
30 autorise avant de rctoumer un bon de caisse ou un refus de paiement. 

Us operations d'authentification de client et d'autorisation de paiement 
seront decrites plus loin en detail en reference a la figure 4. 

Lorsque les verifications effectuees ne permettent pas d'autoriser le 
paiement, une notification de refus rootivce est adrcsscc au client par le serveur de 
35 paiement (indiquant, par excmple, compte insuffisamroent approvisionne, 
depassement d'un seuil autorise pour le client, ...) 
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Loisque les verifications effechiees pcrmcttent d'autoriser 1c paiemcnt, 
Ics informations contcnucs dans Ic ticket de paiemcnt sont completees avec un 
numero de serie dans le registre des transactions 45, une estampille horaire, une 
duree de validity (typiquement quelqucs dizaines de secondes) et le sceau du 
5 serveur de paiement constituant une information de certification. L'ensemble de 
ccs informations, 6ventuellement aprts signature nura6rique par l'utilisation dc la 
partie de clef privee d'un systeme de chiffrement a clef privee/clef publiquc du 
serveur de paiement (ce qui garantit la validite et I'integrite de l'autorisation de 
paiement), est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
10 bon de caisse ou URL de livraison : 

URL http : <M> <descriptif du bon de caisse> , 
ou <M> est l'adresse "Internet" du marchand. 

(6) Demande de livraison 

Le bon de caisse est transrais au serveur du marchand via le poste 
15 client. Ceci peut etre effectue automatiquement par le logiciel implante au poste 
client en utilisant la possibilite de re-routage des URL bien comiuc de Ihomme du 
metier. Avant d'autoriser la livraison du bien, le serveur du marchand opfcre un 
decodage et une verification du bon de caisse rc^u. Cctte verification consiste a 
utiliser la clef privee eventuelle du serveur de paiement, a verifier que la durcc dc 
20 validity n'est pas ecoulee, et a rapprocher le contenu du bon de caisse avec celui dc 
la demande de paiement. 

(7) Livraison du bien 

Lorsque le bon dc caisse est valide par le serveur du marchand, celui- 
ci peut effectuer la livraison dircctc sur le poste client, dans le cas de bien 
25 deformation, ou adressc au poste client un document pennettant lc retrait du bien 
et prfcisant notamment le lieu de livraison et le nom du recipiendaire. 

On notera que, dans le cas d'un achat group6 (panier), il y a creation 
par lc serveur du marchand d'un objet avec affectation d'une identite unique. Cet 
objet est la listc des URL de chacun des biens du panier. Cest cet objet qui est 
30 indique dans lTJRL de commande dc bien et qui permettra d'enregistrer le detail 
des biens achetfe dans le registre de transaction du serveur de paiement. 

Les figures 4A a 4C montrcnt les operations effectu 6es par le serveur 
dc paiement 40 en reponse a la inception d'un ordrc de paiement. 

Dans Ignite frontale 41 (figure 4A), Tordre de paiement est d£cod6 
35 (etape 61) et sa validite est examinee (test 62) notamment du point de vue de la 
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durce de validitc. Si lc rcsultat dc l'examen est negatif, une notification de refus est 
envoyee au poste client (etape 63). 

Si le resultat de Tcxamen est positif, il est precede ensuite a une 
authentification du client (etape 64), le detail de cette operation etant d6crit plus 

5 loin en reference a la figure 4C. Si l'authentification est negative (test 65), une 
notification dc refus est envoyee au client (etape 63). Si elle est positive, l'ordrc de 
paiemcnt (dventuellement lirnite a l'identite CId du client, a l'identite Mid du 
marchand, ct au prix) est transmis via la liaison 68 a l'unite dorsale 42 du serveur 
de paiement represente sur la figure 2 (ctape 66). La liaison 48 est une liaison 

10 securisee interdisant I'acccs a l'unite doreale a toute peisonne se connectant sur le 
reseau 10. 

L'unite frontale 41 attend alois que l'unite dorsale decide d'autoriser ou 
non le paiement (etape 67). Si le paiemcnt n'est pas autorise, (test 68), une 
notification de refus est envoyee au poste client (etape 63). Si le paiement est 
15 autorise, un bon de caisse est clabore (etape 69), utilisant les informations 
enregistrees a l'6tape 62. Lc bon de caisse est enrcgistre dans une mdmoire dc 
1'unite frontale 41 (ctape 70) et est adresse au serveur du marchand via lc poste 
client (ctape 71). 

Au niveau de l'unite dorsale 42 (figure 4B) du serveur dc paiement, a la 
20 reception d'un ordre de paiement authentic, il est examine si eclui-ci doit ctre 
autorise a partir du compte client PME via le reseau bancaire 50. A cet effet, le 
prix est compare a un seuil minimum (test 72). Ce seuil est par exemple de 
quelques dizaines de francs. 

Si lc seuil est depasse, une demande pour effectuer l'operation de 
25 paiement est lancee sur le reseau bancaire (etape 73) en utilisant l'identite bancaire 
correspondant a l'identite CId du client, telle qu'cllc ressort de la consultation de la 
base de denudes 44. A la reception de la reponse positive ou negative (6tapc 74), 
celle-ci est transmise a l'unite frontale 41 (etape 75). 

Si le seuil n'est pas depasse, le paiemcnt pcut etre effectue a partir du 

30 compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionne 
(test 76). Dans la negative, un refus d'autorisation de paiement, e'est-a-dire une 
reponse negative, est renvoyec a l'unite frontale (etape 75). Dans l'affirmative, le 
compte PME du client est debite du prix et le compte TCE de marchand 

35 correspondant a l'identite Mid est credite du meme montant (etape 77), la 
transaction est inscrite dans lc registre des transactions 45 (etape 78) ct 
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1'autorisation de paiement, c'est-a-dire unc reponse positive est transmise a J'unite 
frontaJe 41 avec I'indication du numero de seric de I'inscription dans le registrc de 
transactions (etape 75). 

La procedure d'authentiOcation dans le serveur de paiement (figure 
4Q, a I'etope 64 de la figure 4A, comprend I'envoi au poste client, de preference 
dans une forme securisee (cbiffree), d'une demande de cl£ d'acces, ou mot de passe 
(etape 641). A la reception securisee de la cl<£ d'acces (6tape 642), une comparison 
est effectuee avec une information correspondantc contenuc dans la base de 
donnees 44 (test 643). 

Si la comparison est negative, et qu'un nombre maximum de 
tentatives infmctueuses n'a pas ete atteint (test 644), on retoume a I'ctape 641. Si cc 
nombre maximum est atteint, I'absence d'authentification est constatee, une alerte 
est produite (etape 645) et une reponse negative est envoyee au poste client (etape 
646). L'alerle peut consistcr en une annulation du compte PME ou en une 
15 surveillance de celui-ci afm de detecter de nouvelles tentatives d'utilisation. Si le 
test a I'etape 643 est positif, 1'authentification est enrcgistree (6tape 647) et une 
reponse positive est elaboree (etape 648). 

Des techniques de chiffrement permettant la transmission securisee 
d'informations numeriques sur reseau informatique, notamment pour la demande 
20 d'envoi de cle d'acces et I'envoi de celle-ci, sont bien connues. 

La procedure d'authentification decrit ici permet d'effectuer une 
authentification prealable d'un client dans le cas ou ceile-ci est nccessaire avant 
l^tablissement d'une demande de paiement par le serveur du marchand. Pour cette 
authentification, il suffit alors en effet de creer un ticket de paiement dans lequel le 
25 prix indique est nul, comme indiqud plus baut. 

L'cnregistrement des bons de caisse dans 1'unite frontaJe permet aux 
clients et aux marchands de procetlcr a des contrdles et d'en obtemr eventuelleracnt 
des copies. L'enregisrrement des transactions dans I'unitd dorsale permet d'en 
conserver une rrace en cas, par exemple, de contestation cntre un client et un 
30 marchand. 

Lcs comptes clients PME gcr6s par le serveur de paiement ont cn 
principc un montant de soldc plafonn6 et, selon le mode de realisation prefere de 
I'invention, ils ne sont pas rcmuneres (le systeme de paiement se trouvant en 
dehors du monde bancaire). Un reapprovisionnement de son compte PME par un 
35 client peut etre effectue a partir de son compte bancaire, par ordre donn6 a son 
etablisseracnt bancaire. 
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Lcs comptcs marchands TCE geres par le seiveur dc paicmcnt sont 
associes a des cornptes bancaires reels des marchands dans lesquels ils sont vides 
par exemple quotidiennement. 

Bien que Ton ait decrit ci-avant un mode de mise cn oeuvre d'un 

5 procede selon l'invention dans un environnement "Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, I'horame de l'ait comprendra aisement que le 
procede peut ctre mis en oeuvre avec un reseau informatique autre qu' n lntcrnet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des procedds d'authcntification securisds mettant en jeu 

10 des dispositifs materiels tcls que lectcur de carte a puce ou moyen de 
reconnaissance d'empreinte vocale pourront etre prevus a la place de clefs d'acefcs. 
Ces demieres et d'autre modifications qui viendront a 1'esprit du rbomme du metier 
sont comprises dans la philosophic et la portee dc la prcsente invention. 
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REVINDICATIONS 

1. Proc£d6 de paiement electronique pour des transactions lices a Tachat 

dc biens offerts par des marchands a des clients via un reseau informatique ouvert 
sur lcque] sont connect es des posies serveurs de marchands et des postcs clients, 
5 caractcrise par les etapes de : 

- elaboration par un poste serveur de marchand connects au reseau 
d'une demande d'autorisation de transaction, ou ticket dc paiement, concemant un 
achat envisage entre le marchand et un client, et cornportant des informations 
relatives au marchand, au client, a l'objet de Tachat et a son prix, 

10 _ transmission du ticket de paiement via ie reseau informatique a un 

serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par le serveur de paiement si le paiement du 
prix est autorise pour lc client concerne, la verification etant effectuee, selon le 
montant du prix a payer, soit par interrogation d'un compte client propre au client, 

15 tenu par le serveur de paiement, et destine au paiement des petits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 
paiements de montants plus 61ev6s, 

- si la verification est positive, Elaboration par le serveur de paiement 
d'une autorisation dc transaction ou bon de caisse cornportant au moins une partie 

20 des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de Tachat. 

2. Precede selon la revendication 1, caractcrise en ce que lorsqu'un bon 
de caisse est transmis apres verification par interrogation d'un compte client tenu 
par le serveur de paiement, le montant de Tachat est debite du compte client et 
cnSdite sur un compte marchand propre au marchand concerne et tenu par le 
serveur de paiement. 

3. Precede selon Tune quelconque des rcvendications 1 et 2, caractense 
en ce que la verification par le serveur de paiement comprend une phase prealable 

30 d'autbentification du client. 

4. Precede selon la revendication 3, caracterisE en ce que 
Tauthentification est realise* par reconnaissance d'une clef d'acces transmise par le 
reseau informatique du poste client au serveur de paicment. 

5. Precede selon Tune quelconque des rcvendications 1 a 4, camdense" en 
cc qu'il comprend Telaboration par le serveur de paicment d'un bon de caisse 
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comport ant au moins une partie dcs informations du ticket dc paiement et une 
information dc certification. 

6. Procede selon Tune quelconque des revendications 1 a 5, caracterise en 
ce qu'il comprend la memorisation par le serveur de paiement des transactions 

5 autorisees, par stockage d'au moins une partie du contenu des bons dc caisse. 

7. Procede selon Tune quelconque des revendications 1 a 6, caracterise en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur de 
paiement par I'interm6diaire du poste client. 

8. Procede selon Tune quelconque des revendications 1 a 7, caracterise en 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par l'intermediaire du poste client. 

9. Systeme de paiement electronique pour effectuer des transactions liees 
a 1'achat de biens offerts par des marchands a des clients via un reseau infonnatique 
ouvert, le systeme comport ant des postes clients et dcs postes servcurs dc 

15 marchands pouvant etre connect cs sur 1c reseau ouvert, 

systeme caracterise en ce qu'il com port e en outre au moins un poste serveur de 
paiement distinct des postes clients et serveurs de marchands et comprenant : 

- une unit6 frontale munie de moyens de connexion au rfceau ouvert, 

- une unite dorsale munie de moyens de connexion a un reseau 
20 bancaire independant du reseau ouvert, 

- des moyens dc communication cntrc les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
fournisseurs, et 

- des moyens de traitement pour, en reponse a la reception par Tunit6 
25 frontale d'une demande d'autorisation de transaction ou ticket de paiement, 

concernant un achat envisag6 entre un marchand et un client, v6rifier si le paiement 
du prix est autorise pour le client conceme par interrogation du compte du client 
ou du reseau bancaire et, si la verification est positive, 61aborer une autorisation de 
transaction, ou bon de caisse afin dc la transmettre sur le reseau ouvert via Tunit6 
30 frontale. 

10. Systeme de paiement selon la revendication 9, caracterise en ce que le 
serveur de paiement comprend des moyens de memorisation des transactions 
autoris6es. 
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